REMARKS 

Claims 1-44 and 46-48 are pending. Claims 1-7, 9-10, 12, and 42-47 stand rejected under 35 
U.S.C. § 102(e) as being anticipated by U.S. Patent No. 6,721,784 Bl to Leonard et al. Claims 8, 1 1, 
13-41, and 48 stand rejected under 35 U.S.C. § 103(a) as being unpatentable over Leonard in view of 
U.S. Patent No. 6,078,921 to U.S. Patent No. 6,078,921 Kelley. 

Reconsideration is requested. No new matter is added. Claims 1 and 13 are amended. Claim 
51 is added. Claims 1-44, 46-48, and 51 remain in the case for consideration. 

On the Office Action Summary page of the Office Action dated February 27, 2006, the 
Examiner indicated that claim 45 was withdrawn from consideration. The Applicant respectfully 
points out that claim 45, while canceled in response to the Office Action dated September 9, 2005, 
was in the elected group of claims, and so was not withdrawn from consideration. 

The Applicant notes that the Examiner has indicated that "Applicant's amendment 
necessitated the new ground(s) of rejection presented in this Office Action. Accordingly, THIS 
ACTION IS MADE FINAL" (see Office Action dated February 27, 2006, page 17; emphasis in 
original). The finality of this Office Action may be correct, but the Applicant respectfully submits 
that the Applicant's amendment did not necessitate new grounds of rejection: for example, 
independent claim 1 had not previously been amended, and independent claim 26 has yet to be 
amended. The Examiner has merely repeated the grounds for rejection from the Office Action dated 
September 9, 2006. 

REBUTTAL TO EXAMINER'S RESPONSE TO ARGUMENTS 
In response to "Point A", the Examiner argues that Leonard teaches the limitations of the 
claims. The Examiner states that "applicant rightfully admits 'Leonard teaches: software with an 
origination component and a viewing component integrated together'" (see Office Action dated 
February 27, 2006, page 16). The Examiner appears to treat this as an admission that the features of 
the claims are taught, as the Examiner then says that "[fjhis is a clear anticipation of the invention 
and the rejection ... is maintained" (Id.). 

The Applicant respectfully submits the Examiner misunderstood the Applicant's argument. 
The Applicant did indeed state that "Leonard teaches software with an origination component and a 
viewing component integrated together" (see Response to Office Action dated September 9, 2005, 
page 10). But the "origination component" is not the same as the message (i.e., "information to be 
displayed"). The origination component is software that is used to originate the message. Leonard 
makes this distinction. For example, Leonard recites that "it will be appreciated that any message 
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sent from the message origination software . . ." (see Leonard, column 15, lines 45-46). Leonard 
reinforces this point in the drawings: for example, in figure 7. It is also worth noting that in figures 
9, 10, and 11, Leonard changes terminology: instead of referring to "message origination software", 
Leonard refers to "message creation and sending software". While linguistically this is a different 
term it should be apparent that "message origination software" and "message creation and sending 
software" are actually the same piece of software. 

Figure 7 of Leonard further exemplifies the fact that the message and the viewer are not 
bundled together. In figure 7, the e-mail is sent from the sender to the recipient. But the viewer 
applet, if needed by the recipient, is retrieved from a central e-mail server, which is not along the 
same path as the message travels between the sender and recipient. 

The, Applicant's statement that the origination component and the viewing component might 
be integrated is not the same as teaching information (e.g., a message) contained with the viewer in a 
single file. The Applicant's statement was therefore not an admission that Leonard anticipates the 
claimed invention, but rather just a mere statement of fact about Leonard, which fact contradicts 
anticipation. Leonard fails to teach or suggest that the rich media file can include information and a 
viewer in a single file. Thus, claims 1, 42, and 46 are patentable under 35 U.S.C. § 102(e) over 
Leonard. Accordingly, claims 1, 42, and 46 are allowable, as are dependent claims 2-12, 43-45, and 
47-48. 

In response to "Point B", the Examiner contends that Leonard teaches '"building a message 
that includes only controls that are intended by the origination of the message' is taught by Leonard" 
(see Office Action dated February 27, 2006, page 16). The Examiner cited to column 23, lines 55-61 
of Leonard in support of this assertion. 

The Applicant respectfully submits that the Examiner again misunderstood the Applicant's 
argument. First, claim 12 recites a "viewer including] only a capability desired by a builder of the 
rich media file". Thus, in claim 12, it is the viewer capabilities that are included or not, not message 
features. 

Second, as claim 12 recites a "viewer including] only a capability desired by a builder of the 
rich media file", by implication, the viewer omits any capabilities the builder does not desire. The 
motivation to omit capabilities not desired is to keep the viewer size small, which in turn reduces the 
amount of time needed to receive the rich media file (which includes the viewer). In contrast, 
Leonard only describes the "MCS records ... as a basis for varying the controls or limitations placed 
on a message" (see Leonard, column 23, lines 55-56). By including the MCS record in the message, 
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Leonard provides greater flexibility for the sender of the message - the sender can enable or disable 
particular features in the viewer. But the viewer applet always includes all capabilities: the MCS 
record simply controls whether those features are available to the recipient of the message. Thus, 
Leonard does not teach or suggest a "viewer including] only a capability desired by a builder of the 
rich media file". Claim 12 is therefore patentable under 35 U.S.C. § 102(e) over Leonard, and is 
therefore allowable. 

In response to "Point C" and "Point D", the Examiner merely refers to the rejections of 
claims 13 and 14: the Examiner has therefore not specifically responded to the Applicant's 
arguments. According to MPEP § 707.07(f), "[w]here the applicant traverses any rejection, the 
examiner should, if he or she repeats the rejection, take note of the applicant's argument and answer 
the substance of it". As the Examiner has merely referred to the statement of rejection, the Examiner 
has not answered the substance of the Applicant's arguments. 

REJECTIONS UNDER 35 U.S.C. § 102(e) 

Claim 1 is directed toward a rich media file stored in a machine-readable medium, 
comprising: information to be displayed on a computer system, the information including text and at 
least one image; and a viewer designed to display the information on the computer system, the 
information and the viewer contained in a single file. 

Claim 42 is directed toward a memory for storing a platform-independent rich media file 
including a data structure stored in said memory, comprising: information for the rich media file; a 
unique identification for the rich media file; a version number for the rich media file; a viewer for 
displaying the information; and at least one viewing option for the rich media file. 

Claim 46 is directed toward a memory for storing a database of rich media files including a 
data structure stored in said memory, comprising: a rich media file, the rich media file including 
information and a viewer to view the information; a profile of a user who downloaded the rich media 
file; a client who generated the rich media file; and a log storing a transaction in the data structure. 

Claims 1, 42, and 46 of the application all include information to be displayed on a computer 
screen and a viewer to display the information, with both these components built into a single file. 

In contrast, Leonard teaches a system and method for enabling the originator of an electronic 
mail message to preset an expiration time, date, and/or event, and to control and track processing or 
handling by all recipients. Leonard uses message origination software to create an email message, 
and FIGs. 1 and 6-8 show that the message origination software can be integrated with a viewer 
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applet to view the message. By integrating the message origination software with the viewer applet, 
Leonard allows users to enable and disable message controls and features for viewing the message. 

Leonard teaches integrating the origination software with the viewer applet in column 18, 
lines 53-55 saying, "the viewer and origination software are combined into a single program." 
Although Leonard teaches software with an origination component and a viewing component 
integrated together, Leonard does not teach a viewer applet contained with the message itself in a 
single file as recited in claim 1. Indeed, column 14, lines 51-55 describes "retaining the message on 
the electronic mail server and requiring the recipient to view the message using the viewer applet". 
Later in column 14, lines 60-63, Leonard says that the viewer applet retains only "transient storage of 
the message. Since the message exists only on server 1 . . ." This reference to transient storage of the 
message should make it clear that the applet is not part of the message itself. Rather, Leonard is clear 
in that a message is not transmitted to the user with the viewer applet, but instead the viewer applet is 
used to allow the viewer to view the message that is stored on the electronic mail server. 

In arguing that Leonard teaches the message and viewer applet as a single file, the Examiner 
has cited to column 9, lines 28-30, where Leonard teaches "a simple viewer applet that can be 
distributed to the recipient with the message whose lifespan is to be controlled." Even though 
Leonard teaches a viewer applet distributed with a message, he still does not teach that the viewer 
applet and the message are contained in a single file as claimed. Indeed, Leonard suggests otherwise 
in column 15, lines 13-16, where Leonard teaches that to forward a message, a recipient must first 
download a viewer applet if necessary, and then the message is transmitted to the installed viewer 
applet. The fact that Leonard teaches that a viewer applet can be already be downloaded on a 
recipient's computer shows that the message is in fact not stored in or with the viewer applet itself. 
If the message were stored on the applet, then it would not make sense for Leonard teach that a user 
can reuse a previously downloaded viewer applet, when a new message is forwarded to a recipient. 

Thus, it should be clear that Leonard fails to teach, and in fact even teaches away from, 
combining the viewer applet with the message itself in a single file. Because Leonard does not teach 
or suggest this feature, claims 1, 42 and 46 are not anticipated by Leonard. Thus, claims 1, 42, and 
46 are patentable under 35 U.S.C. § 102(e). Accordingly, claims 1, 42, and 46, as well as dependent 
claims 2-12, 42-44, 47, and 48 are allowable. 

Claim 12 is directed toward a rich media file according to claim 1, wherein the viewer 
includes only a capability desired by a builder of the rich media file. 
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As described in the specification on page 6, lines 1-11, viewing options are built into 
modules that may be included or excluded from the rich media file depending on the preference of 
the creator of the rich media file. By allowing the inclusion or exclusion of modular components, the 
creator is able to create a rich media file that has no unnecessary overhead. For example, a rich 
media file creator could desire that users viewing the file be allowed to print the file while viewing 
the file and include the printing module in the build of the rich media file. By including the printing 
module, the rich media file will have to include the printing module, and will thus have the overhead 
of the printing module included. Another file creator could instead prefer that users not be able to 
print the rich media file, and thus would exclude the printing module from the rich media file. By 
excluding the printing module, the storage that would be required to include in the rich media file 
will not be necessary, and therefore the file can be smaller. By including only the desired features, 
the rich media file is able to stay as small as possible, making it easier to transmit over networks. 

Leonard does not teach building a message that includes only controls that are intended by 
the originator of the message. Instead, Leonard teaches control by providing disablement of 
undesired features. In column 16, lines 12-26, Leonard teaches "in the message header, as mentioned 
above, are fields for including control information used to enable or disable electronic mail 
processing or handling functions. ..." By allowing features to be disabled by setting a field in a file 
header, Leonard makes clear that the viewer applet includes all features; the message sender can 
choose to disable certain features, but not remove them from the viewer applet. Thus, the viewer 
applet does not include "only a capability desired by the builder of the rich media file". 

By teaching a system where control of features that are to be included in the message resides 
in a header for the message, Leonard does not teach building a rich media file, where some control 
components are included or excluded based on the intent of the creator. While this approach does 
provide for flexibility in creating and managing messages, Leonard's approach does not address the 
additional issue of creating a file that is only as large as it must be to provide the desired features. 

Because Leonard fails to teach a viewer including only a capability desired by a builder of a 
rich media file, claim 12 is not anticipated by Leonard. Therefore, claim 12 is patentable under 35 
U.S.C. § 102(e), and claim 12 is allowable. 

REJECTIONS UNDER 35 U.S.C. § 103(a) 
Claim 1 3 is directed toward a rich media file stored in a machine-readable medium, 
comprising: information to be displayed on a computer system, the information including an image 
and compressed using a compression technique; a viewer designed to display the information on the 
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computer system; limit means for limiting viewing of the rich media file, the limit means drawn from 
a setting defining a predetermined number of viewings of the information, a setting defining a 
predetermined number of days, a predetermined expiration date, and a password controlling access to 
the rich media file; checking means for checking if there is a later version of the rich media file; a 
query asking a user if the user would like to retrieve the later version of the rich media file; retrieval 
means for retrieving the later version of the rich media file; and a unique file identification for the 
rich media file in addition to a file name. 

Claim 14 is directed toward a method for retrieving a rich media file, the method comprising: 
selecting a link on a network; downloading the rich media file over the network based on a unique 
file identification other than the link and other than a file name, the rich media file including a viewer 
and information to be displayed in the viewer; and saving the rich media file on a computer system. 

Claim 26 is directed toward a method for building a unitary rich media file, the method 
comprising: assembling information for the unitary rich media file; formatting the information; 
coupling the information with a viewer; and converting the information and the viewer to the unitary 
rich media file, so that the unitary rich media file is designed to leave no footprint on a user's system 
when removed. 

As with the independent claims discussed above with reference to the 35 U.S.C. § 102(e) 
rejection, claims 13,14, and 26 are also directed to a rich media file including a rich media file viewer 
along with information to be displayed by the viewer. As previously discussed above, rather than 
teaching this feature of the present application, Leonard actually teaches away from this feature. 

The Examiner has not cited to Kelley as teaching this feature, and the Applicant believes that 
Kelley in fact does not teach this feature. Kelley teaches a method and apparatus for providing a self- 
service file. Kelley does not teach or suggest a special viewer for the self-service file, but instead, as in 
column 7, lines 53-54, Kelley teaches a "browser application or any other multi-part file viewer." 

Furthermore, claim 13 includes a unique file identification for the rich media file in addition to a 
file name, and claim 14 downloads a file based on a unique file identification other than the link and 
other than a file name. While Leonard might suggest a unique file identification by teaching message 
attributes included in a header, Leonard does not provide a single unique file identification for a rich 
media file that guaranties a unique identifier other than a file name. According to column 10, lines 63- 
66, attributes that are provided by Leonard can include the date the message is created, time the message 
is sent, the sender, and a title or name of the message. Even in combination, these attributes do not 
necessarily uniquely identify a message: for example, a single message that is copied to multiple people 
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would share all the same attributes, but the copies going to different recipients are different messages. 
Thus, it is misleading to call these attributes a unique message identifier. 

Finally, Leonard is concerned with the creation of email messages, and does not teach or suggest 
creating links to rich text files. The Examiner cites to Kelley as teaching the feature of downloading a 
rich media file over a network based on a unique file identification other than the link and other than a 
file name. In column 8, lines 24-64, Kelley teaches downloading a file over a link. However, Kelley 
does not teach accomplishing this by using a unique file identification other than the link or name of the 
file. In fact, Kelley does not even teach a unique file identification different from a file name. 

As neither Leonard nor Kelley teach a unique file identification in addition to a file name, 
particularly a unique file identification that is used in downloading a file over the network, these features 
of claims 13 and 14 are not or suggested by Leonard or Kelley. Further, neither reference teaches or 
suggests combining the compressed information with the viewer into a single file as included in claims 
13, 14, and 26. Thus claims 13, 14 and 26 are patentable under 35 U.S.C. § 103(a). Accordingly, claims 
13, 14, and 26 are allowable, as are dependent claims 15-25, 27-41, and 51. 

Claim 29 is directed to a method according to claim 26, wherein formatting the information 
includes selecting viewing options to include with the rich media file. 

As previously discussed this allows the creator of the rich media file flexibility in creating a file 
having only the file overhead required to support the desired capabilities, while excluding overhead for 
undesired features. 

As discussed above, Leonard does not teach or suggest building a rich media file with only the 
desired capabilities, but instead teaches that undesired capabilities can be disabled as reflected in a 
header. While disablement might by useful in that it prevents the recipient of the rich media file from 
using the file in a way undesirable to the creator, disablement still includes overhead in the file that the 
present application is directed to avoid. 

Similarly, Kelley also fails to teach or suggest that only desired capabilities or viewing options 
are built into a rich media file. Kelley teaches a method and apparatus for providing a self-service file. 
The Examiner has not cited to Kelley as teaching or suggesting this feature. Furthermore, the Applicant 
does not believe that Kelley teaches or suggests this feature. 

Because neither Leonard nor Kelley teach or suggest building a rich media file with only desired 
capabilities or viewing options, claim 29 is patentable under 35 U.S.C. § 103(a). Accordingly claim 29 
is allowable. 
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For the foregoing reasons, reconsideration and allowance of claims 1-44, 46-48, and 51 of the 
application as amended is solicited. The Applicant requests that the Examiner telephone the 
undersigned at (503) 222-3613 to schedule an interview. 



Respectfully submitted, 

MARGER JOHNSON & McCOLLOM, P.C. 

Ariel S. Rogson ^ 
Registration No. 43,054 

210 S.W. Morrison Street, Suite 400 
Portland, Oregon 97204 
Telephone: (503)222-3613 
Customer No. 20575 
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